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BACKGROUND OF THE INVENTION 

A. Field of the Invention 

This invention generally relates to data processing systems and, more particularly, to 
leasing delegation certificates in data processing systems. 

B. Description of the Related Art 

Proper resource management is an important aspect to efficient and effective use of 
computers. In general, resource management involves allocating resources (e.g., memory) in 
response to requests as well as deallocating resources at appropriate times, for example, when 
the requesters no longer require the resources. In general, the resources contain data 
referenced by computational entities (e.g., applications, programs, applets, etc.) executing in 
the computers. 

In practice, when applications executing on computers seek to refer to resources, the 
computers must first allocate or designate resources so that the applications can properly refer 
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to them. When the applications no longer refer to a resource, the computers can deallocate or 
reclaim the resource for reuse. In computers each resource has a unique "handle" by which 
the resource can be referenced. The handle may be implemented in various ways, such as an 
address, array index, unique value, pointer, etc. 

Resource management is relatively simple for a single computer because the events 
indicating when resources can be reclaimed, such as when applications no longer refer to 
them or after a power failure, are easy to determine. Resource management for distributed 
systems connecting multiple computers is more difficult because applications in several 
different computers may be using the same resource. 

Disconnects in distributed systems can lead to the improper and premature 
reclamation of resources or to the failure to reclaim resources. For example, multiple 
applications operating on different computers in a distributed system may refer to resources 
located on other machines. If connections between the computers on which resources are 
located and the applications referring to those resources are interrupted, then the computers 
may reclaim the resources prematurely. Alternatively, the computers may maintain the 
resources in perpetuity, despite the extended period of time that applications failed to access 
the resources. 

These difficulties have led to the development of systems to manage network 
resources, one of which is known as "distributed garbage collection." That term describes a 
facility provided by a language or runtime system for distributed systems that automatically 
manages resources used by an application or group of applications running on different 
computers in a network. 

In general, garbage collection uses the notion that resources can be freed for future use 
when they are no longer referenced by any part of an application. Distributed garbage 
collection extends this notion to the realm of distributed computing, reclaiming resources 
when no application on any computer refers to them. 

Distributed garbage collection must maintain integrity between allocated resources 
and the references to those resources. In other words, the system must not be permitted to 
deallocate or free a resource when an application running on any computer in the network 
continues to refer to that resource. This reference-to-resource binding, referred to as 
"referential integrity," does not guarantee that the reference will always grant access to the 
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resource to which it refers. For example, network failures can make such access impossible. 
The integrity, however, guarantees that if the reference can be used to gain access to any 
resource, it will be the same resource to which the reference was first given. 

Distributed systems using garbage collection must also reclaim resources no longer 
being referenced at some time in the finite future. In other words, the system must provide a 
guarantee against "memory leaks." A memory leak can occur when all applications drop 
references to a resource, but the system fails to reclaim the resource for reuse because, for 
example, of an incorrect determination that some application still refers to the resource. 

Referential integrity failures and memory leaks often result from disconnections 
between applications referencing the resources and the garbage collection system managing 
the allocation and deallocation of those resources. For example, a disconnection in a network 
connection between an application referring to a resource and a garbage collection system 
managing that resource may prevent the garbage collection system from determining whether 
and when to reclaim the resource. Alternatively, the garbage collection system might 
mistakenly determine that, since an application has not accessed a resource within a 
predetermined time, it may collect that resource. A number of techniques have been used to 
improve the distributed garbage collection mechanism by attempting to ensure that such 
mechanisms maintain referential integrity without memory leaks. One conventional approach 
uses a form of reference counting, in which a count is maintained of the number of 
applications referring to each resource. When a resource's count goes to zero, the garbage 
collection system may reclaim the resource. Such a reference counting scheme only works, 
however, if the resource is created with a corresponding reference counter. The garbage 
collection system in this case increments the resourced reference count as additional 
applications refer to the resource, and decrements the count when an application no longer 
refers to the resource. 

Reference counting schemes, however, especially encounter problems in the face of 
failures that can occur in distributed systems. Such failures can take the form of a computer 
or application failure or network failure that prevent the delivery of messages notifying the 
garbage collection system that a resource is no longer being referenced. If messages go 
undelivered because of a network disconnect, the garbage collection system does not know 
when to reclaim the resource. 



99A4130A1 l_> 



WO 99/44130 PCT/US99/03400 

6 

To prevent such failures, some conventional reference counting schemes include 
"keep-alive" messages, which are also referred to as "ping back." According to this scheme, 
applications in the network send messages to the garbage collection system overseeing 
resources and indicate that the applications can still communicate. These messages prevent 
the garbage collection system from dropping references to resources. Failure to receive such 
a "keep-alive" message indicates that the garbage collection system can decrement the 
reference count for a resource and, thus, when the count reaches zero, the garbage collection 
system may reclaim the resource. This, however, can still result in the premature reclamation 
of resources following reference counts reaching zero from a failure to receive "keep-alive" 
messages because of network failures. This violates the referential integrity requirement. 

Another proposed method for resolving referential integrity problems in garbage 
collection systems is to maintain not only a reference count but also an identifier 
corresponding to each computational entity referring to a resource. See A. Birrell, et al., 
"Distributed Garbage Collection for Network Objects," No. 116, digital Systems Research 
Center, December 15, 1993. This method suffers from the same problems as the reference 
counting schemes. Further, this method requires the addition of unique identifiers for each 
computational entity referring to each resource, adding overhead that would unnecessarily 
increase communication within distributed systems and add storage requirements (i.e., the list 
of identifiers corresponding to applications referring to each resource). 

SUMMARY OF THE INVENTION 
In accordance with the present invention, referential integrity is guaranteed without 
costly memory leaks by leasing resources for a period of time during which the parties in a 
distributed system, for example, an application holding a reference to a resource and the 
garbage collection system managing that resource, agree that the resource and a reference to 
that resource will be guaranteed. At the end of the lease period, the guarantee that the 
reference to the resource will continue lapses, allowing the garbage collection system to 
reclaim the resource. Because the application holding the reference to the resource and the 
garbage collection system managing the resource agree to a finite guaranteed lease period, 
both can know when the lease and, therefore, the guarantee, expires. This guarantees 
referential integrity for the duration of a reference lease and avoids the concern of failing to 



■NSDOCID: <WO. 



.99441 30A1 J_> 



WO 99/44130 PCT/US99/O34O0 

7 

free the resource because of network errors. In addition to memory, the leasing technique can 
be applied to delegation certificates. 

Consistent with an alternative embodiment of the present invention, as embodied and 
broadly described herein, a method for leasing delegation certificates is provided. This 
method comprises the steps of receiving a lease request from a client specifying a resource 
and a lease period, determining a lease period during which the client has authority to request 
from a server access to the resource, advising the client of the granted lease period, granting 
the client a delegation certificate which the client can use to access the resource from the 
server. 

BRIEF DESC RIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute a part of this 
specification, illustrate an embodiment of the invention and, together with the description, 
serve to explain the advantages and principles of the invention. In the drawings, 

FIG. 1 is a flow diagram of the steps performed by the application call processor 
according to an implementation of the present invention; 

FIG. 2 is a flow diagram of the steps performed by the server call processor to process 
dirty calls according to the implementation of the present invention; 

FIG. 3 is a flow diagram of the steps performed by the server call processor to process 
clean calls according to the implementation of the present invention; 

FIG. 4 is a flow diagram of the steps performed by the server call processor to initiate 
a garbage collection process according to the implementation of the present invention. 

FIG. 5 is a diagram of a preferred flow of calls within a distributed processing system; 

FIG. 6 is a block diagram of the components of the implementation of a method 
invocation service according to the present invention; 

FIG. 7 is a diagram of a distributed processing system that can be used in an 
implementation of the present invention; and 

FIG. 8 is a diagram of the individual software components in the platforms of the 
distributed processing system according to the implementation of the present invention. 
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FIG. 9 is a diagram of a data processing system for leasing delegation certificates in a 
distributed processing system that can be used in an alternative embodiment of the present 
invention; and 

FIG. 10 is a flow diagram of the steps performed by the delegator process when 
another process (potential delegatee) requests a lease according to an alternative embodiment 
of the present invention; and 

FIG. 1 1 A and FIG. 1 IB represent a flow diagram of the steps performed by a process 
(potential delegatee) when requesting a lease from the delegator process according to an 
alternative embodiment of the present invention; and 

FIG. 12 is a flow diagram of the steps performed by the server when a delegatee 
requests access to a resource according to an alternative embodiment of the present invention. 

DETAILED DESCRIPTION 
Reference will now be made in detail to an implementation of the present invention as 
illustrated in the accompanying drawings. Wherever possible, the same reference numbers 
will be used throughout the drawings and the following description to refer to the same or like 
parts. 

The present invention may be implemented by computers organized in a conventional 
distributed processing system architecture. The architecture for and procedures to implement 
this invention, however, are not conventional, because they provide a distributed garbage 
collection scheme that ensures referential integrity and eliminates memory leaks. 

A. Overview 

A method invocation (ML) component located in each of the computers in the 
distributed processing system implements the distributed garbage collection scheme of this 
invention. The MI component may consist of a number of software modules preferably 
written in the JAVA 7 ^ programming language. 

In general, whenever an application in the distributed processing system obtains a 
reference to a distributed resource, by a name lookup, as a return value to some other call, or 
another method, and seeks to access the resource, the application makes a call to the resource 
or to an MI component managing the resource. That MI component, called a managing MI 
component, keeps track of the number of outstanding references to the resource. When the 
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number of references to a reference is zero, the managing MI component can reclaim the 
resource. The count of the number of references to a resource is generally called the 
"reference count" and the call that increments the reference count may be referred to as a 
"dirty call." 

When an application no longer requires a distributed resource, it sends a different call 
to the resource or the managing MI component. Upon receipt of this call, the managing MI 
component decrements the reference count for the resource. This call to drop a reference may 
be referred to as a "clean call." 

In accordance with an implementation of the present invention, a dirty call can include 
a requested time interval, called a lease period, for the reference to the resource. Upon receipt 
of the dirty call, the managing MI component sends a return call indicating a period for which 
the lease was granted. The managing MI component thus tracks the lease period for those 
references as well as the number of outstanding references. Consequently, when the reference 
count for a resource goes to zero or when the lease period for the resource expires, the 
managing MI component can reclaim the resource. 

B. Procedure 

An application call processor in an MI component performs the steps of the 
application call procedure 100 illustrated in FIG. 1 . The server call processor in the 
managing MI component performs the steps of the procedures 200, 300, and 400 illustrated in 
FIGs. 2-4, respectively. The managing MI component's garbage collector performs 
conventional procedures to reclaim resources previously bound to references in accordance 
with instructions from the server call processor. Accordingly, the conventional procedures of 
the garbage collector will not be explained. 

1. Application Call Processor 

FIG. 1 is a flow diagram of the procedure 100 that the application call processor of the 
MI component uses to handle application requests for references to resources managed by the 
same or another MI component located in the distributed processing system. 

After an application has obtained a reference to a resource, the application call 
processor sends a dirty call, including the resource's reference and a requested lease period to 
the managing MI component for the resource (step 110). The dirty call may be directed to 
the resource itself or to the managing MI component. 
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The application call processor then waits for and receives a return call from the 
managing MI component (step 120). The return call includes a granted lease period during 
which the managing MI component guarantees that the reference of the dirty call will be 
bound to its resource. In other words, the managing MI component agrees not to collect the 
resource corresponding to the reference of a dirty call for the grant period. If the managing 
MI component does not provide a grant period, or rejects the request for a lease, then the 
application call processor will have to send another dirty call until it receives a grant period. 

The application call processor monitors the application's use of the reference and, 
either when the application explicitly informs the application call processor that the reference 
is no longer required or when the application call processor makes this determination on its 
own (step 130), the application call processor sends a clean call to the managing MI 
component (step 140). In a manner similar to the method used for dirty calls, the clean call 
may be directed to the referenced resource and the managing MI component will process the 
clean call. Subsequently, the application call processor eliminates the reference from a list of 
references being used by the application (step 150). 

If the application is not yet done with the reference (step 130), but the application call 
processor determines that the grant period for the reference is about to expire (step 1 60), then 
the application call processor repeats steps 110 and 120 to ensure that the reference to the 
resource is maintained by the managing MI component on behalf of the application. 
2. Server Call Processor 

The MI component's server call processor performs three main procedures: (1) 
handling dirty calls; (2) handling incoming clean calls; and (3) initiating a garbage collection 
cycle to reclaim resources at the appropriate time. 

(i) Dirty Calls 

FIG. 2 is a flow diagram of the procedure 200 that the MI component's server call 
processor uses to handle requests to reference resources, i.e., dirty calls, that the MI software 
component manages. These requests come from application call processors of MI 
components in the distributed processing system, including the application call processor of 
the same MI component as the server call processor handling requests. 

First, the server call processor receives a dirty call (step 210). The server call 
processor then determines an acceptable grant period (step 220). The grant period may be the 
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same as the requested lease period or some other time period. The server call processor 
determines the appropriate grant period based on a number of conditions including the 
amount of resource required and the number of other grant periods previously granted for the 
same resource. 

When the server call processor determines that a resource has not yet been allocated 
for the reference of a dirty call (step 230), the server call processor allocates the required 
resource (step 240). 

The server call processor then increments a reference count corresponding to the 
reference of a dirty call (step 250), sets the acceptable grant period for the reference-to- 
resource binding (step 260), and sends a return call to an application call processor with the 
grant period (step 270). In this way, the server call processor controls incoming dirty calls 
regarding references to resources under its control. 

Applications can extend leases by sending dirty calls with an extension request before 
current leases expire. As shown in procedure 200, a request to extend a lease is treated just 
like an initial request for a lease. An extension simply means that the resource will not be 
reclaimed for some additional interval of time, unless the reference count goes to zero. 

(ii) Clean Calls 

The MI components server call processor also handles incoming clean calls from 
application call processors. When an application in the distributed processing system no 
longer requires a reference to a resource, it informs the MI component managing the resource 
for that reference so that the resource may be reclaimed for reuse. Fig. 3 is a flow diagram of 
the procedure 300 with the steps that the MI component's server call processor uses to handle 
clean calls. 

When the server call processor receives a clean call with a reference to a resource that 
the MI component manages (step 310), the server call processor decrements a corresponding 
reference count (step 320). The clean call may be sent to the resource, with the server call 
processor monitoring the resource and executing the procedure 300 to process the call. 
Subsequently, the server call processor sends a return call to the MI component that sent the 
clean call to acknowledge receipt (step 330). In accordance with this implementation of the 
present invention, a clean call to drop a reference may not be refused, but it must be 
acknowledged. 
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(iii) Garbage Collection 
The server call processor also initiates a garbage collection cycle to reclaim resources 
for which it determines that either no more references are being made to the resource or that 
the agreed lease period for the resource has expired. The procedure 400 shown in FIG. 4 
includes a flow diagram of the steps that the server call processor uses to initiate a garbage 
collection cycle. 

The server call processor monitors reference counts and granted lease periods and 
determines whether a reference count is zero for a resource managed by the MI component, or 
the grant period for a reference has expired (step 410). When either condition exists, the 
server call processor initiates garbage collection (step 420) of that resource. Otherwise, the 
server call processor continues monitoring the reference counts and granted lease periods. 

C. Call Flow 

FIG. 5 is a diagram illustrating the flow of calls among MI components within the 
distributed processing system. Managing MI component 525 manages the resources 530 by 
monitoring the references to those resources 530 (see garbage collect 505). Because the 
managing MI components 525 manages the resources, the server call processor of managing 
MI component 525 performs the operations of this call flow description. 

FIG. 5 also shows that applications 510 and 540 have corresponding MI components 
515 and 545, respectively. Each of the applications 510 and 540 obtains a reference to one of 
the resources 530 and seeks to obtain access to one of the resources 530 such that a reference 
is bound to the corresponding resource. To obtain access, applications 510 and 540 invoke 
their corresponding MI components 515 and 545, respectively, to send dirty calls 551 and 
571, respectively, to the MI component 525. Because the MI components 515 and 525 handle 
application requests for access to resources 530 managed by another MI component, such as 
managing MI component 525, the application call processors of MI components 515 and 545 
perform the operations of this call flow description. 

In response to the dirty calls 551 and 571, managing MI component 525 sends return 
calls 552 and 572, respectively, to each of the MI components 515 and 545, respectively. The 
dirty calls include granted lease periods for the references of the dirty calls 551 and 571 . 
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Similarly, FIG. 5 also shows MI components 515 and 545 sending clean calls 561 and 
581, respectively, to managing MI component 525. Clean calls 561 and 581 inform 
managing MI component 525 that applications 510 and 540, respectively, no longer require 
access to the resource specified in the clean calls 561 and 581 . Managing MI component 525 
responds to clean calls 561 and 581 with return calls 562 and 582, respectively. Return calls 
562 and 582 differ from return calls 552 and 572 in that return calls 562 and 582 are simply 
acknowledgments from MI component 525 of the received clean calls 561 and 581. 

Both applications 510 and 540 may request access to the same resource. For example, 
application 510 may request access to "RESOURCECl)" while application 540 was 
previously granted access to that resource. MI component 525 handles this situation by 
making the resource available to both applications 510 and 540 for agreed lease periods. 
Thus, MI component 525 will not initiate a garbage collection cycle to reclaim the 
"RESOURCE(l)" until either applications 510 and 540 have both dropped their references to 
that resource or the latest agreed periods has expired, whichever event occurs first. 

By permitting more than one application to access the same resource simultaneously, 
the present invention also permits an application to access a resource after it sent a clean call 
to the managing MI component dropping the reference to the resource. This occurs because 
the resource is still referenced by another application or the reference's lease has not yet 
expired so the managing MI component 525 has not yet reclaimed the resource. The 
resource, however, will be reclaimed after a finite period, either when no more applications 
have leases or when the last lease expires. 

D. MI Components 

FIG. 6 is a block diagram of the modules of an MI component 600 according to an 
implementation of the present invention. MI component 600 can include a reference 
component 605 for each reference monitored, application call processor 640, server call 
processor 650, and garbage collector 660. 

Reference component 605 preferably constitutes a table or comparable structure with 
reference data portions 610, reference count 620, and grant period register 630. MI 
component 600 uses the reference count 620 and grant period 630 for each reference specified 
in a corresponding reference data portion 610 to determine when to initiate garbage collector 
660 to reclaim the corresponding resource. 
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Application call processor 640 is the software module that performs the steps of 
procedure 100 in FIG. 1 . Server call processor 650 is the software module that performs the 
steps of procedures 200, 300, and 400 in FIGs. 2-4. Garbage collector 660 is the software 
module that reclaims resources in response to instructions from the server call processor 650, 
as explained above. 

E. Distributed Processing System 

FIG. 7 illustrates a distributed processing system 50 which can be used to implement 
the present invention. In FIG. 7, distributed processing system 50 contains three independent 
and heterogeneous platforms 100, 200, and 300 connected in a network configuration 
represented by the network cloud 55. The composition and protocol of the network 
configuration represented in FIG. 7 by the cloud 55 is not important as long as it allows for 
communication of the information between platforms 700, 800 and 900. In addition, the use 
of just three platforms is merely for illustration and does not limit the present invention to the 
use of a particular number of platforms. Further, the specific network architecture is not 
crucial to this invention. For example, another network architecture that could be used in 
accordance with this invention would employ one platform as a network controller to which 
all the other platforms would be connected. 

In the implementation of distributed processing system 50, platforms 700, 800 and 
900 each include a processor 710, 810, and 910 respectively, and a memory, 750, 850, and 
950, respectively. Included within each processor 710, 810, and 910, are applications 720, 
820, and 920, respectively, operating systems 740, 840, and 940, respectively, and MI 
components 730, 830, and 930, respectively. 

Applications 720, 820, and 920 can be programs that are either previously written and 
modified to work with the present invention, or that are specially written to take advantage of 
the services offered by the present invention. Applications 720, 820, and 920 invoke 
operations to be performed in accordance with this invention. 

MI components 730, 830, and 930 correspond to the MI component 600 discussed 
above with reference to FIG. 6. 

Operating systems 740, 840, and 940 are standard operating systems tied to the 
corresponding processors 710, 810, and 910, respectively. The platforms 700, 800, and 900 
can be heterogenous. For example, platform 700 has an UltraSparc® microprocessor 



BNSDOCID: <WO 99441 30A1_I_> 



WO 99/44130 PCT/US99/03400 

15 

manufactured by Sun Microsystems Corp. as processor 710 and uses a Solaris® operating 
system 740. Platform 800 has a MIPS microprocessor manufactured by Silicon Graphics 
Corp. as processor 810 and uses a Unix operating system 840. Finally, platform 900 has a 
Pentium microprocessor manufactured by Intel Corp. as processor 910 and uses a Microsoft 
Windows 95 operating system 940. The present invention is not so limited and could 
accommodate homogenous platforms as well. 

Sun, Sun Microsystems, Solaris, Java, and the Sun Logo are trademarks or registered 
trademarks of Sun Microsystems, Inc. in the United States and other countries. UltraSparc 
and all other SPARC trademarks are used under license and are trademarks of SPARC 
International, Inc. in the United States and other countries. Products bearing SPARC 
trademarks are based upon an architecture developed by Sun Microsystems, Inc. 

Memories 750, 850, and 950 serve several functions, such as general storage for the 
associated platform. Another function is to store applications 720, 820, and 920, MI 
components 730, 830, and 930, and operating systems 740, 840, and 940 before execution by 
the respective processor 710, 810, and 910. In addition, portions of memories 750, 850, and 
950 may constitute shared memory available to all of the platforms 700, 800, and 900 in 
network 50. 

E. MI Services 

The present invention may be implemented using a client/server model. The client 
generates requests, such as the dirty calls and clean calls, and the server responds to requests. 

Each of the MI components 730, 830 and 930 shown in FIG. 7 preferably includes 
both client components and server components. FIG. 8, which is a block diagram of a client 
platform 1000 and a server platform 1 100, applies to any two of the platforms 700, 800, and 
900 in FIG. 7. 

Platforms 1000 and 1100 contain memories 1050 and 1150, respectively, and 
processors lOlOand 1110, respectively. The elements in the platforms 1000 and 1100 
function in the same manner as similar elements described above with reference to FIG. 7. In 
this example, processor 1010 executes a client application 1020 and processor 1110 executes 
a server application 1 120. Processors 1010 and 1110 also execute operating systems 1040 
and 1140, respectively, and MI components 1030 and 1130, respectively. 
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MI components 1030 and 1 130 each include a server call processor 1031 and 1131, 
respectively, an application call processor 1032 and 1 132, respectively, and a garbage 
collector 1033 and 1 133, respectively. Each of the MI components 1030 and 1130 also 
contains reference components, including reference data portions 1034 and 1 134, 
respectively, reference counts 1035 and 1 135, respectively, and grant period registers 1036 
and 1 136, respectively, for each reference that the respective MI component 1030 or 1 130 
monitors. 

Application call processors 1032 and 1 132 represent the client service and 
communicate with server call processors 103 1 and 1131, respectively, which represent the 
server service. Because platforms 1000 and 1 100 contain a server call processor, an 
application call processor, a garbage collector, and reference components, either platform can 
act as a client or a server. 

For purposes of the discussion that follows, however, platform 1000 is designated the 
client platform and platform 1 100 is designated as the server platform. In this example, client 
application 1020 obtains references to distributed resources and uses MI component 1030 to 
send dirty calls to the resources managed by MI component 1 130 of server platform 1 100. 

Additionally, server platform 1 100 may be executing a server application 1 120. 
Server application 1 120 may also use MI component 1 130 to send dirty calls, which may be 
handled by MI component 1 130 when the resources of those dirty calls are managed by MI 
component 1 130. Alternatively, server application 1 120 may use MI component 1 130 to 
send dirty calls to resources managed by MI component 1030. 

Accordingly, server call processor 1031, garbage collector 1033, and reference count 
1035 for MI component 1030 of client platform 1000 are not active and are therefore 
presented in FIG. 8 as shaded. Likewise, application call processor 1 132 of MI component 
1 130 of the server platform 1 100 is shaded because it is also dormant. 

When client application 1020 obtains a reference corresponding to a resource, 
application call processor 1032 sends a dirty call, which server call processor 1131 receives. 
The dirty call includes a requested lease period. Server call processor 1131 increments the 
reference count 1 135 for the reference in the dirty call and determines a grant period. In 
response, server call processor 1131 sends a return call to application call processor 1030 
with the grant period. Application call processor 1032 uses the grant period to update 
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recorded grant period 1 035, and to determine when the resource corresponding to the 
reference of its dirty call may be reclaimed. 

Server call processor 1 131 also monitors the reference counts and grant periods 
corresponding to references for resources that it manages. When one of its reference counts 
1 135 is zero, or when the grant period 1 135 for a reference has expired, whichever event 
occurs first, server call processor 1 131 may initiate the garbage collector 1 133 to reclaim the 
resource corresponding to the reference that has a reference count of zero or an expired grant 
period. 

The leased-reference scheme according to the implementation of the present invention 
does not require that the clocks on the platforms 1000 and 1 100 involved in the protocol be 
synchronized. The scheme merely requires that they have comparable periods of increase. 
Leases do not expire at a particular time, but rather expire after a specific time interval. As 
long as there is approximate agreement on the interval, platforms 1000 and 1 100 will have 
approximate agreement on the granted lease period. Further, since the timing for the lease is, 
in computer terms, fairly long, minor differences in clock rate will have little or no effect. 

The transmission time of the dirty call can affect the protocol. If MI component 1030 
holds a lease to reference and waits until just before the lease expires to request a renewal, the 
lease may expire before the MI component 1 130 receives the request. If so, MI component 
1 130 may reclaim the resource before receiving the renewal request. Thus, when sending 
dirty calls, the sender should add a time factor to the requested lease period in consideration 
of transmission time to the platform handling the resource of a dirty call so that renewal dirty 
calls may be made before the lease period for the resource expires. 

F. Copclusjop 

In accordance with the present invention a distributed garbage collection scheme 
ensures referential integrity and eliminates memory leaks by providing granted lease periods 
corresponding to references to resources in the distributed processing system such that when 
the granted lease periods expire, so do the references to the resources. The resources may 
then be collected. Resources may also be collected when they are no longer being referenced 
by processes in the distributed processing system with reference to counters assigned to the 
references for the resources. 
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Alternative Embodiment of the Present Invention 

The leasing technique, described above, relates to garbage collection. However, an 
alternative embodiment of the present invention, as described below, can be used with 
delegation certificates. 

A delegation certificate allows one actor ("a delegator") with sufficient privilege to 
access a resource to delegate its authority to access this resource to another actor ("a 
delegatee") who then accesses the resource on behalf of the delegator. 

However, for security purposes, the delegator may not want to delegate to the 
delegatee carte blanche permission to access the resource for fear the delegatee may abuse its 
privilege either intentionally or unintentionally. Thus, the delegator may want to impose 
limits on the delegatee's access, such as the type of access permitted or the length of time 
access is permitted. The leasing of delegation certificates allows the delegator to control and 
limit the delegatee ! s access, thus providing additional security. 

Delegation certificates can be leased to access various resources, such as files. An 
example of a delegation follows: a delegator may have confidential tax files managed by a file 
system manager. By prior negotiation, the file system manager will only grant access to these 
files to the owner, the delegator. However, the owner may need the taxes to be calculated by 
a tax program, so the owner delegates authority to the tax program, the delegatee, to access 
the tax files for a limited time, until April 15. Accordingly, the owner grants the tax program 
permission, via a delegation certificate, to access the files controlled by the file system 
manager until April 15th. This is accomplished by leasing the delegation certificate to the tax 
program such that the lease expires on April 15th. If the tax program attempts to access the 
file after this date, the lease expires and it is prevented from doing so by the file system 
manager. 

The leasing of delegation certificates allows the owner to control or limit access to the 
files by the tax program. More specifically, the tax program requests a lease from the owner 
for access to the files stored with the file system manager for read access until April 15th. If a 
lease is granted, the owner sends to the tax program a delegation certificate that indicates the 
tax program is entitled to read-only access to the owner's files. 

The file system manager has the responsibility of authenticating the delegation 
certificate as well as to determine the type and length of the tax program's access. At no time 
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can the tax program directly change the contents of the delegation certificate. However, the 
tax program can request the owner to renew the lease (i.e., if the tax program requires 
additional time to access the file) or to cancel the lease, (i.e., if the tax program's access is 
completed before the lease period expires). 

The delegation certificate is an object that proves the identity of the delegator and has 
a set of corresponding rights attached to it. In particular, the delegation certificate object 
contains a principal identifier, some means for proving the identification, and a specification 
of the rights. The specification of the rights includes methods for determining the type of 
access requested and the duration of a lease. In addition, the object includes methods for 
canceling a lease and for renewing a lease. Finally, the methods may generate exceptions 
that, when accessed, set forth the reason why invocation of the method was unsuccessful. 

The object is an instance of a class that may be extended in many ways to offer more 
functionality, but the basic class is defined as follows: 

interface Lease { 

obj FileHandle; 

public void getldentfier (); 

public void getAuthentication (); 

public void getAccesstype 0; 

public long getDuration (); 

public void renew (long renewDuration) throws 

LeaseDeniedException, 

UnknownLeaseException, 

RemoteException; 
public void cancel () throws 

UnknownLeaseException, 

RemoteException 

} 

The principal identifier gives the delegatee the appearance of being the delegator 
when the delegatee communicates with the system manager. The integrity of the 
identification is assured by any number of known authentication methods, such as public-key, 
challenge-response protocol, or shared secret technology. 

Invoking the access type method provides the type of access the delegator permits. 
This method can be invoked by whoever has the delegation certificate, either the delegator, 
the delegatee, or the file system manager. For instance, the delegatee will invoke the method 
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to determine what type of access it is permitted to seek from the file system manager. The 
file system manager will invoke the method to determine what type of access it is permitted to 
grant. For example, the delegator may deem a particular file as read-only access. In this case, 
the file system manager will only allow read access for a subsequently granted lease for that 
particular file. Conversely, an attempt by the delegatee to write to that storage location would 
not be permitted by the file system manager. 

Invoking the duration method provides the length of the granted lease period. This 
period represents the most recent lease granted by the delegator. 

The renew method permits the renew of the lease, asking for more time, without 
having to re-initiate the original lease request. Situations where the delegatee may desire to 
renew the lease include when the original lease proves to be insufficient (i.e., the delegatee 
requires additional use of the storage location), or when only a partial lease (i.e., less than the 
requested lease) is granted. 

In addition, the renew method can be continually invoked in order to obtain sequential 
lease periods. The renew method, however, cannot be invoked if the delegatee does not have 
an active lease. Also, the renew method has no return value; if the renewal is granted, the 
new lease period will be reflected in the lease object on which the call was made. If the 
delegator is unable or unwilling to renew the lease, the reason is set forth in the 
LeaseDeniedException generated by the renew method. 

The cancel method is invoked when there is still time left on the lease, but the 
delegatee no longer desires access. The cancel method may also be invoked by the delegator 
if, for instance, it wants to cancel the delegatee's access. Thus, cancel allows the file, for 
example, to be reclaimed. In contrast, upon the end of a lease, (i.e., natural termination 
occurs), there is no notification obligation by the delegatee. 

Figure 9 depicts a data processing system 9000 suitable for use for by an alternative 
embodiment of the present invention. The data processing system 9000 includes a computer 
system 9002 connected to the Internet 9004. The computer system 9002 includes a memory 
9010, a secondary storage device 9018, a central processing unit (CPU) 9024, an input device 
9026, and a video display 9022. The secondary storage device 901 8 further includes a 
number of files 9020. The memory 9010 further includes a delegator program 9008, a 
delegatee program 9010, and an operating system 9014 containing a file system manager 
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9016. The file system manager 9016 manages files 9020 on the secondary storage device 
9018. The delegatee 9010 requests access to a secondary storage device 9018 by requesting a 
lease from the delegator 9008. In response, the delegator 9008 may either grant or deny the 
lease as further described below. If the delegator 9008 grants the lease to the delegatee 9010, 
the delegatee 9010 then requests access to the secondary storage device 901 8 from the file 
system manager 9016. One skilled in the art will appreciate that computer 9000 may contain 
additional or different components. 

Although aspects of the alternative embodiment are described as being stored in 
memory 901 0, one skilled in the art will appreciate that these aspects may also be stored in 
other computer readable media, such as secondary storage devices, like hard disks, floppy 
disks, or CD-ROM; a carrier wave from the Internet 9004; or other forms of RAM or ROM. 

Figure 10 depicts a flow chart of the steps performed by the delegator 9008 when 
receiving a lease request from the delegatee 9010. The first step performed by the delegator 
is to request the delegatee to access a resource, such as a file, on the delegator's behalf (step 
10002). At some point later, the delegator will receive a lease request from the delegatee 
(step 10004). This request is a function call that includes a number of parameters including 
(1) the requested file the delegatee wishes to lease, (2) the desired lease period, and (3) the 
type of access the delegatee desires. 

The requested file parameter contains an indication of the file to be leased. The 
desired lease period contains an amount of time the delegatee wants to utilize the file. The 
type of access requested indicates the type of access the client requested. For example, the 
delegatee may request read access or write access. To form a valid request, the delegatee 
request must contain both the file desired and the desired lease. After receiving the request, 
the delegator examines the parameters to verify the propriety of the request (step 10006). 

After examining the parameters, the delegator determines if the request is, in fact, 
proper (step 10008). For example, the delegator checks if the requested file is a file that the 
delegator has the ability to lease. Also, the delegator verifies that some lease period is 
specified. Additionally, the delegator checks if the type of access requested is available. If 
the delegator determines that the lease request is improper, the delegator generates an 
exception (step 10010) and processing ends. 
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If the delegator determines that the lease request is proper, the delegator determines a 
sufficient lease period (step 10012). For example, if access to the delegator's tax files are 
requested, the delegator may grant a lease period up to April 15. Next, the delegator creates a 
lease object and returns the object to the delegatee (step 10020) and processing ends. 

Figures 1 1 A and 1 IB depict a flowchart of the steps performed by the delegatee 9010 
when requesting a lease from the delegator 9008. The first step performed by the potential 
delegatee is to receive a request by the delegatee that entails accessing a file on the delegator's 
behalf (step 1 1001). At some point later, the delegatee sends a request for a lease to the 
delegator (step 1 1002). This request is a function call and is described in step 10004 in figure 
10. 

After sending the request, the delegatee receives a lease object from the delegator 
(step 1 1004). The lease object, as described above, includes the principal identifier, the 
authentication method, the access-type method, the lease duration method, the renew method, 
the cancel method. 

Next, the delegatee, by examining the lease object, determines if a lease was granted 
(step 1 1006). If the delegatee determines that a lease was not granted, the delegatee invokes 
the exception method (step 1 1008), which allows the delegatee to determine why a lease was 
not granted. If the delegatee determines that the lease was not granted because of an improper 
request (step 1 1010), the delegatee reconfigures the request (step 1 1012), and processing 
continues to step 1 1002. However, if the delegatee determines that the lease was not granted 
for reasons other than an improper request, processing ends. Note, the delegator may grant 
multiple leases to the same file, since it is ultimately the responsibility of the file system 
manager to referee actual access to the file. 

If the delegatee, in step 1 1006, determines that a lease was granted by the delegator, 
next the delegatee requests access to the file from the file system manager, by sending an 
access request (step 1 1018). Processing then continues to step 1 1020 in Fig. 1 IB. 

After the delegatee sends the access request to the file system manager in step 11018 
in figure 1 1 A, the delegatee determines, by examining the lease object, if the file system 
manager granted the delegatee access to the file (step 1 1020). If the delegatee determines that 
access was not granted by the file system manager, the delegatee invokes the exception 
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method, contained in the object returned by the file system manager, which allows the 
delegatee to determine why access was not granted (step 1 1022). 

If the delegatee determines that access was not granted because of an improper request 
(step 1 1024), processing ends. On the other hand, if the request was proper, the delegatee 
determines if access was not granted because the file system manager allocated the file to 
another leaseholder (step 1 1026). If the delegatee determines the file is busy, the delegatee 
waits for a predetermined period of time (step 1 1028) and processing continues to step 11018 
in Fig. 1 1 A. If the delegatee determines that access to the file was denied for some other 
reason, processing ends. 

If the delegatee determines, in step 1 1020, that the file system manager granted the 
delegatee access to the file, then the delegatee can access the file (step 11030). Next, the 
delegatee determines if it is finished accessing the file (step 1 1 032). 

If the delegatee ! s use is completed, the delegatee determines if the lease expired, (i.e., 
the lease is no longer active) (step 1 1034). If the lease expired, processing ends and no 
communication is necessary between the delegatee and the file system manager (i.e., natural 
termination occurs). Otherwise, if the lease is still active the delegatee invokes the cancel 
method (step 1 1 036). The delegatee accesses the cancel method via the lease object. The 
cancel method informs the file system manager and the delegator that the delegatee is no 
longer interested in the file. Accordingly, the cancel method allows the file system manager 
to reclaim the file for use by other lease holders in an expeditious fashion. 

If the delegatee determines in step 1 1032 that it still desires access to the file, the 
delegatee determines if the lease is about to expire (step 1 1038). This is achieved by the 
delegatee comparing the duration of the lease with current time minus the time when the lease 
was granted. The duration of the lease is found by invoking the duration method. If the lease 
is not about to expire, the delegatee continues to access the file (step 1 1030). 

However, if the lease is about to expire in step 11038, the delegatee must decide 
whether or not to renew the lease (step 1 1040). If the delegatee chooses to renew the lease, 
the delegatee invokes the renew method of the lease object. If the renew method is invoked, 
processing continues to step 1 1002 in Fig. 1 1A. If the delegatee does not renew the lease, 
then processing ends and no communication is necessary between the delegatee and the file 
system manager (i.e., natural termination occurs). 
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Figure 12 depicts a flow chart of the steps performed by the file system manager 9016 
when a delegatee process 9008 requests access to a file. The first step performed by the file 
system manager is to receive an access request by the delegatee (step 1202). After receiving 
the request, the file system manager authenticates the delegatee's identity by invoking the 
principal identifier method and the authentication method, via the lease object (step 1203). If 
the file system manager determines that the delegated lacks the proper identity to access the 
file (step 1204), the file system manager generates an exception (step 1206) and processing 
ends. 

If the file system manager determines in step 1204 that the delegated identity is 
authentic, the file system manager invokes the getAccess type method (step 1208). By 
invoking the getAccess type method, the file system manager is able to determine which type 
of access the delegatee desires. Next, the file system manager determines if the file is 
available for the type of access requested (step 1210). If the file system manager determines 
that the file is unavailable, the file system manager generates an exception (step 1206) and 
processing ends. 

If the file system manager determines, in step 1210, that the file is available, the file 
system manager invokes the duration method (step 1212). The file system manager invokes 
the duration method in order to determine if there is time left on the delegatee's lease. If the 
file system manager determines that the delegatee's lease is active (step 1214), the file system 
manager grants the delegatee access to the file (step 1218). After granting the delegatee 
access to the file, the file system manager returns to step 1212. 

If the file system manager determines in step 1214 that the lease is not active, the file 
system manager will reclaim the file (step 1216). After reclaiming the file, the file system 
manager generates an exception (step 1206) and processing ends. 

The foregoing description of an implementation of the invention has been presented 
for purposes of illustration and description. It is not exhaustive and does not limit the 
invention to the precise form disclosed. Modifications and variations are possible in light of 
the above teachings or may be acquired from practicing of the invention. For example, the 
described implementation includes software but the present invention may be implemented as 
a combination of hardware and software or in hardware alone. The scope of the invention is 
defined by the claims and their equivalents. 
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WHAT IS CLAIMED IS: 

1 . A method in a processing system, comprising the steps of: 

receiving a lease request from a program, the lease request specifying a resource and a 

requested lease period; 

determining a lease period during which the program has authority to access the 

resource; and 

sending to the program a delegation certificate for use by the program to access the 
resource during the determined lease period. 
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